Many new communications devices and related services have emerged, to allow people to communicate freely as they roam, without the need for a fixed network connection. In particular, modern digital public wireless telephone networks offer customers a wide range of voice and data communication services combined with a high degree of mobility. In this context, situations arise in which it is desirable to obtain information about the physical or geographic location of a mobile communication terminal and/or its user. For example, if a cellular telephone user encounters an emergency situation, the user dials 911 or the like; and the emergency response center needs to know the actual location of the telephone and thus of the caller to direct emergency response personnel to the correct place. As another example, some carriers offer services in which authenticated third parties may request the location of a subscriber's mobile station. Services are also known in which the user at the mobile station itself may request location information and/or information about the surrounding geographic locale for display on or audio presentation from the mobile station.
To support such services, a network architecture has been developed that includes a position determining entity (PDE), which requests and processes position related data to determine the location of a mobile device. For example, if the mobile device is equipped with a global positioning satellite (GPS) receiver, the PDE will request and process GPS data from the mobile station to determine the latitude and longitude of the mobile station. However, certain problems have been found with the signaling procedure used to request and direct the necessary data to the PDE. To appreciate the problems, it may be helpful to consider network architecture and the signaling involved in a GPS based location procedure, in somewhat more detail.
In Assisted GPS, the Position Determining Entity (PDE) determines the actual Latitude and Longitude of the mobile based on GPS measurements taken by the mobile station at the PDE's request. The process of locating a mobile telephone station using Assisted GPS (AGPS) involves several elements. In practice, a Mobile Positioning Center (MPC) or other similar element requests location information for a particular mobile telephone station from the PDE. The mobile switching center (MSC) serving the mobile station delivers messages to/from the mobile station, including those exchanged with the PDE. The request and response messages between the PDE and the mobile station (via the MSC) take the form of ANSI-41 SMDPP data burst messages with IS-801 defined bearerdata.
A problem has arisen due to interference in the network to mobile data burst messaging, which causes the MSC to reject a SMDPP Invoke message from the PDE with a return result marking SMSCause Code 33—“Destination Busy.” As one example, this may occur if the PDE's acknowledgement (Ack) of an earlier message from the MSC and an Invoke message from the PDE are received in reverse order by the MSC. Normally, the PDE acknowledges the last message from the MSC, and then it may send a further Invoke message. The MSC expects an acknowledgement (Ack) prior to any such new Invoke messages. When the MSC receives a new Invoke message before the acknowledgement (Ack) of its last preceding message, the MSC replies with SMSCause Code 33 (Destination Busy). Previously the PDE stopped call processing upon receiving the Cause Code. Hence, call flows would be terminated prematurely, and the PDE was unable to locate the mobile device.
FIG. 3 depicts the signal flow involved in an exemplary prior art procedure for determining the location of a mobile device having a GPS receiver. As shown, in step S31, the PDE initiates the AGPS call flow, by sending a first SMDPP Invoke message (#1) to the MSC, via the SS7 network, and the MSC delivers that message to the mobile telephone station via the air interface. The BearerData of the message contains an IS-801 Position Determination Data Message (PDDM) for the mobile station. An example of what the first message might be is a “Request Mobile Station Info” message.
In the next step (S32), the MSC acknowledges receipt of the first Invoke message by sending an SMDPP return result message containing an acknowledgement (Ack). Although not shown as a separate step, the mobile telephone station replies to the PDE's message via the air interface; and in response, the MSC packages the PDDM response data message in an upstream SMDPP Invoke message, for delivery via the Signaling System 7 (SS7) network to the PDE (step S33). An example of what the reply message might be is a “Provide Mobile Station Info” message, for example, to supply requested data on functional capabilities from the mobile station to the PDE for further processing. The process of requesting and obtaining data from the mobile station in this manner requires two or more successive message exchanges, of this type, in order to supply all of the necessary data to the PDE to allow the PDE to resolve the GPS information and compute the latitude and longitude of the mobile station's current location.
After the Invoke message (S33) from the MSC, the PDE must now acknowledge receipt and initiate its next request to the mobile telephone station for more data. Hence, in step S34, the PDE sends an acknowledgement (Ack), in an SMDPP return result message, back to the MSC. The PDE then sends a second SMDPP Invoke message (Invoke #2), for example, a “Request Pilot Phase Measurement” message or a “Request Pseudo Range Measurement” message (S35). To distinguish the Ack and second Invoke messages in the drawing, the SMDPP return result type acknowledgement (Ack) message is shown in dashed-line form, whereas the subsequent SMDPP Invoke #2 message is shown as a solid line. At step S36, due to network latency, divergent paths, or other issues, the PDE's acknowledgement (Ack) message and the second Invoke message actually arrive at the MSC in reverse order (as shown to the left), as compared to the order in which they were sent (as shown to the right). Because of the order of arrival, at step S37, the MSC rejects the PDE's second Invoke message, by generating an SMSCauseCode of 33 (Destination Busy). In response, the PDE aborts the call flow. Consequently, because of the reordering of the packet messages between the PDE and the MSC, the attempt to obtain the location information for the mobile station from the MSC breaks down and fails.
This problem is not easily avoided because the ANSI-41 SS7 messages in use are defined in the standard SCCP Class 0, which means that delivery order can not be guaranteed. As noted above, obtaining all necessary data for determining location takes several rounds of requesting data and receiving data from the mobile station via the MSC. Each time either node receives an Invoke message, it must respond with an acknowledgement. In the course of such an AGPS call flow, it is possible to have one or more failure points based on the message order or other network issues. At present, there is no method or mechanism to compensate for these failures. In view of the need to obtain the location information, a need exists for a technique to allow the system to complete the communication of the location information from the MSC to the PDE, despite the reordering of the messages during the packet communication or other similar reasons for the MSC to generate a failure message that would otherwise abort the location process.